1. Field of the Invention
The present invention relates to web services. More particularly, the present invention relates to testing the interoperability of web services across a plurality of web service tools.
2. Description of the Prior Art and Related Information
Services provided over the Internet, commonly referred to as web services or application services, are evolving. Likewise, technologies that facilitate such services are also evolving. A web service may be defined as any information source running business logic processes that is configured for remote use by an application or end-user. Web services provide interoperability between various software applications running on disparate platforms, as they are, for the most part, based upon open standards and protocols. Protocols and data formats are text-based where possible, making it easy for developers to comprehend, making web services the preferred means through which functionality is exposed and accessed over computer networks such as the Internet. Web services typically include some combination of programming and data that are made available from an application server for end users and other network-connected application programs. Web services range from such services as storage management and customer relationship management down to much more limited services and functionality such as the creation of purchase orders.
Web services are commonly described in a machine-processable and structured definition language known as web Services Description Language (WSDL). WSDL, commonly pronounced “wiz-dull”, is an eXtensible Markup Language (XML) format published for describing web services. WSDL describes the public interface to the web service. It is an XML-based service description on how to communicate using the web service; namely, the protocol bindings and message formats required to interact with the web services listed in its directory. The supported operations carried out by the web service and messages are described abstractly, and then bound to a concrete network protocol and message format.
WSDL is often used in combination with SOAP and XML to provide web services over the Internet. SOAP is a protocol for exchanging XML-based messages conveyed over a computer network, normally using Hyper Text Transfer Protocol (HTTP). By utilizing HTTP, web services can work through many common firewall security measures without requiring changes to the firewall filtering rules. SOAP forms the foundation layer of the web services stack, providing a basic messaging framework that more abstract layers can build on. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special data types used are embedded or imported in the WSDL file in the form of XML Schema. The client can then use SOAP to call one of the operations listed in the WSDL.
W3C is the primary committees responsible for the architecture and standardization of web services. To improve interoperability between web service implementations, the WS-I organization has been developing further constraints on WSDL to promote interoperability. WS-I is an open, industry group that was formed in 2002 to promote web services interoperability across platforms, operating systems, and programming languages.
Currently, the web service usage model is generally as follows. Services are implemented and deployed on one site, often referred to as the server side. Services are described using WSDL and are published via means such as UDDI (Universal Description, Discovery, and Integration), which is an XML-based registry for businesses worldwide to list themselves on the Internet by the web services they offer and which enables applications to look up web services information in order to determine whether to use them. Client applications use web services at another site, often referred to as the client side, by first interpreting one or more WSDL documents. Once interpreted, the clients can understand the characteristics of the associated service(s). For example, service characteristics may include service API specifications such as (a) input data type, (b) service input data format, (c) service access mechanism or style (e.g., remote procedure call—RPC—versus messaging), and (d) related encoding format. Client applications prepare their data in manners in which various particular web services understand. Client applications invoke a particular service according to the manner specified for the service, such as in an associated WSDL document.
Many differences exist among web services with respect to the format of input data and the manner in which they are invoked. For example, an application service provider may provide a service “NewPurchaseOrder” that requires a number of input parameters including, for example, a vendor ID and an amount for purchase order. A client application that intends to invoke such a service must be written so that data within or output by the application is able to be analyzed to generate the purchase order. At runtime, the prepared provided input data is passed to the “NewPurchaseOrder” service site using appropriate Application Program Interfaces (APIs). Data types represent a common interoperability problem. SOAP uses serializer and deserializer objects to translate from the native language of a software application to the SOAP protocols that move the request over the wire. It is here where native languages introduce dependencies on the data. For example, the way Java defines date or floating point objects (which may be present in the web service, such as the “NewPurchaseOrder” example developed herein) may be different from the manner in which Microsoft's .NET formats such date and floating point objects. In this manner, SOAP data types with the same name may be formatted differently, causing interoperability issues among the different web services tools. Therefore, in order to test a web service against different web service clients, it is conventionally necessary to write hard coded programs called test cases that are specific to every web service client and every web service. Web services test cases written once cannot typically be applied to every other kind of web service client. Due to the complexity of the various standards involved, however, web service authoring tools are not typically successful in completely conforming to these standards. In the final analysis, however, the aim of testing the interoperability (as opposed to the underlying functionality thereof) of web services is not to test how well a given web service conforms to the WS-I-promulgated standards, but to test the interoperability of the web service against all types of web service clients.
From the foregoing, it may be appreciated that improved methods and systems for testing the interoperability of web services against all types of web clients are needed. What are also needed are computer-implemented methods and systems for testing web services defined by WDSL files against all commonly used web services tools.